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Amendments to the Specification 

Please replace the paragraph on Page 22, lines 6-10 with the following marked-up replacement 
paragraph: 

- Aggregated services may constrain access to their exposed operations to those users 
who have sufficient credentials, and successfully demonstrate these credentials using an exposed 
authorization operation. It may also be advantageous to enable creation of user profiles which 
span [[an]] aggregated services, and optionally to allow these u$er profiles to be queried, 
changed, and/or deleted using corresponding service operations. — 

Please replace the paragraph that begins on Page 23, litre 19 and carries over to Page 24, line 1 0 
with the following marked-up replacement paragraph: 

- Referring now to Figs. 7A and 7B, preferred embodiments of the present invention use 
SOAP messages for communication among web services. The example SOAP message 700 
comprises a SOAP envelope carrying a digital signature in its header, according to the prior art. 
See Fig- 7A for the header 710 and digital signature 720. This digital signature may be used for 
authentication of the requester who submits the service request carried in the SOAP message 
body. See Fig. 7B for the message body 730 and request 740. In this sample message 700, the 
message body specifies a "GetLastTradePrice" message, for which the <m:symbol> child 
element has a value of M IBM". It can be presumed that this is an invocation of a stock quote 
service, and that this service requires the user to be authenticated; the digital signature of the user 
has therefore been supplied in the SOAP header. (Refer to "SOAP Security Extensions: Digital 
Signature, W3C NOTE 06 February 2001 n , which may be found on the Internet at location 
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http://www.w3.org/TR/SOAP-dsig/, for more information about using SOAP messages in this 
manner.) — 

Please replace the paragraph on Page 22, lines 6 - 10 with the following marked~up replacement 
paragraph: 

- The "InUpdateUserProfileRequest" message 518 is analogous to the 
"TnCreateUserProfileRcquesf* message 510, and uses the same parameters in this example. The 
"UpdateUserProftle" operation 560 receives the "InUpdateUserProfjleRequest^ message 518, 
and responds with an "OutUpdateUserProfileResponse" message 520 that is analogous to the 
"OutCreateUserProfileResponse" message S 12. Tn the example, this output message 512 returns 
a Boolean value indicating whether the profile c r eation update was successful or not. - 

Please replace the paragraph that begins on Page 29, line 15 and carries over to Page 30, line 13 
with the following rnarked-up replacement paragraph: 

- Preferably, the authentication token generated in Block 610 is generated as an XML 
fragment, which can then be included in a SOAP message header. In this manner, user identities 
may be relayed when accessing web services. Refer to the di scussion of the sample SOAP 
message 700 in Figs. 7A and 7B, which shows how a digital signature is included in a SOAP 
header using XML syntax. (As shown therein, the digital signature tokens use a qualified 
namespace, and arc therefore preceded by the letters u ds".) Authentication systems and policy 
systems may be bound to service operations using the SOAP header as well. WSDL descriptions 
preferably model operations as a combination of a SOAP header and body. That is, all 
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operations requiring proof of identity preferably require user credentials to be exchanged. The 
SOAP Security Extensions technique used in the examples herein is one example of how this 
may be accomplished. The Security Association Markup Language ("SAML"), the Generic 
Security Service ("GSS") API, and the Common Secure Interoperability ("OSI") architecture also 
provide means for security 1 securely exchanging a principal's credentials. (A version of SAML is 
defined in an OASIS Draft which may be found on the Internet at 

http://www.oasis-opcn.org/con^ dated April 

11 9 200 1 . The GSS-API is defined in RFC 2743, "Generic Security Service Application Program 
Interface, Version 2, Update 1", dated January 2000. CSI is defined in ct Common Secure 
Interoperability V2 Specification**, available on the Internet at 
http://www.omg.org/cgi-bin/doc7ptc/200l-03-02.) - 

Please replace the patagraph that begins on Page 30, line 19 and carries over to Page 3 1 , line 10 
with the following marked-up replacement paragraph: 

— The test in Block 620 checks to see if this user is (still) authenticated globally (that is, 
for the aggregated service). In preferred embodiments, once a user is authenticated, his/her 
credentials are associated with the requests for the remainder of the flow (i.e. the calls according 
to the aggregated service's.) However, the logic in Fig, 6 is designed to perform the test at Block 
620 more than once, for example to account for a user who might log off during the sequence of 
operations specified in the flow model. If the test has a negative result, then this user is not 
allowed to continue operating the aggregated service, and a failure code is preferably returned 
(Block 640), after which the processing of Fig. 6 ends. If the test has a positive result, then 
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processing continues at Block 630, which tests to sec if this user i$ authentically locally (that is, 
for the next service to be performed, where this service is determined according to the WSFL 
flow model). If this test has a negative result, then control transfers to Block [[640]] 650; 
otherwise, control transfers to Block 670. - 

Please replace the paragraph on Page 31, lines 11-13 with the following matked-up replacement 
paragraph: 

- In Block [[625]] £5& the stacked identity information for the next operation to be 
performed is retrieved. This retrieved information is passed to this next operation's 
authentication service, which generates (or retrieves) an operation-specific token using this 
identity information. - 

Please replace the paragraph on Page 34, lines 13-17 with the following marked-up replacement 
paragraph: 

- While the preferred embodiments of the present invention have been described, 
additional variations and modifications in those embodiments may occur to those skilled in the 
art once they learn of the basic inventive concepts. Therefore, it is intended that the appended 
claims shall be construed to include [[both]] the preferred embodim e n t embodiments and all such 
variations and modifications as fall within the spirit and scope of the invention. - 



Serial No. 10/047,81 1 -5- Docket RSW9200101 99US1 



PAGE 7/18 * RCVD AT 5/24/2005 1:16:03 PM [Eastern Daylight Time] * SVR:U$PT0£FXRM4 * DN1S:8729306 * CSID:4073437587 * DURATION (mnws):04«48 



